Windows actions by neykov · Pull Request #30 · neykov/extract-tls-secrets

neykov · 2026-04-01T05:31:40Z

I've asked Claude to reproduce the failure in Issue 7. It needed a lot of handholding, but eventually was able to come up with a clean repro case.

ServiceConfigurationError: WindowsAttachProvider could not be instantiated

Error

java.util.ServiceConfigurationError: com.sun.tools.attach.spi.AttachProvider:
  Provider sun.tools.attach.WindowsAttachProvider could not be instantiated

Root Cause

On Windows with Oracle JDK 8, two separate Java installs coexist:

A JDK at C:\Program Files\Java\jdk1.8.0_XXX\ — has tools.jar and jre\bin\attach.dll
A standalone public JRE at C:\Program Files\Java\jre1.8.0_XXX\ — has no attach.dll

Oracle's installer puts the public JRE's bin\ on the system PATH. Users separately set
JAVA_HOME to the JDK for development tools. This creates the failing combination:

Component	Source	Has `attach.dll`?
`java.exe` on PATH	Standalone public JRE	—
`jvm.dll` loaded	Standalone JRE `bin\server\`	—
`sun.boot.library.path`	Derived from `jvm.dll` location → standalone JRE `bin\`	No
`tools.jar` (via `JAVA_HOME`)	JDK `lib\tools.jar`	✓

Key facts

The standalone JRE does not ship attach.dll — it is only present in the JDK's embedded JRE
(jdk\jre\bin\attach.dll).

sun.boot.library.path is derived purely from the location of the running jvm.dll, not
from JAVA_HOME. It always resolves to the bin\ directory two levels above jvm.dll:

jvm.dll at:  standalone_jre\bin\server\jvm.dll
             ↓ strip \jvm.dll
             standalone_jre\bin\server
             ↓ strip \server
             standalone_jre\bin
             ↓ strip \bin, append \bin
sun.boot.library.path = standalone_jre\bin   ← no attach.dll here

System.loadLibrary("attach") searches sun.boot.library.path first, then java.library.path
(derived from PATH). If neither contains attach.dll, loading fails.

Failure chain

java.exe is the standalone JRE's — com.sun.tools.attach.VirtualMachine is not on the
classpath, so isAttachApiAvailable() returns false.
AgentAttach loads tools.jar from JAVA_HOME via URLClassLoader(cp, null).
VirtualMachine.list() triggers the SPI, which attempts to instantiate
WindowsAttachProvider.
WindowsAttachProvider's static initializer calls System.loadLibrary("attach").
System.loadLibrary searches sun.boot.library.path = standalone JRE bin\ →
attach.dll is absent.
UnsatisfiedLinkError is thrown inside the static initializer.

The SPI loader catches the Throwable and wraps it:

ServiceConfigurationError: Provider sun.tools.attach.WindowsAttachProvider
  could not be instantiated

Variant failure

If any attach.dll is reachable via PATH (e.g. from a different JDK installation), but it is
from an older version than the tools.jar being used, the static initializer succeeds but a
later native method call fails:

java.lang.UnsatisfiedLinkError: sun.tools.attach.WindowsAttachProvider.tempPath()

tempPath() was added in a later JDK 8 update as a security hardening measure. An older
attach.dll on PATH will load successfully but will not contain this method.

Steps to Reproduce

name: Reproduce ServiceConfigurationError - standalone JRE on PATH with JDK JAVA_HOME

on:
  workflow_dispatch:

jobs:
  reproduce:
    runs-on: windows-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up Temurin JDK 8 (JAVA_HOME will point here)
        uses: actions/setup-java@v4
        with:
          java-version: '8'
          distribution: 'temurin'

      - name: Build jar
        run: mvn package -DskipTests -q

      - name: Download Temurin JRE-only archive (simulates Oracle standalone public JRE)
        shell: pwsh
        run: |
          $url = "https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u442-b06/OpenJDK8U-jre_x64_windows_hotspot_8u442b06.zip"
          Invoke-WebRequest -Uri $url -OutFile jre8.zip
          Expand-Archive jre8.zip -DestinationPath jre8
          $jreHome = (Get-ChildItem jre8 -Directory)[0].FullName
          echo "STANDALONE_JRE=$jreHome" >> $env:GITHUB_ENV

      - name: Confirm preconditions
        shell: pwsh
        run: |
          Write-Host "Standalone JRE (simulates java.exe on PATH):"
          Write-Host "  path       : $env:STANDALONE_JRE"
          Write-Host "  attach.dll : $(Test-Path "$env:STANDALONE_JRE\bin\attach.dll")"
          Write-Host ""
          Write-Host "JDK (JAVA_HOME):"
          Write-Host "  path       : $env:JAVA_HOME"
          Write-Host "  tools.jar  : $(Test-Path "$env:JAVA_HOME\lib\tools.jar")"
          Write-Host "  attach.dll : $(Test-Path "$env:JAVA_HOME\jre\bin\attach.dll")"

      - name: Reproduce error
        shell: pwsh
        # Simulates: Oracle standalone JRE on PATH, JAVA_HOME pointing to JDK.
        # java.exe is from the standalone JRE  →  sun.boot.library.path = standalone JRE bin\
        # Standalone JRE has no attach.dll     →  System.loadLibrary("attach") fails
        # UnsatisfiedLinkError in static init  →  SPI wraps as ServiceConfigurationError
        run: |
          # Strip JDK directories from PATH so java.library.path also has no attach.dll fallback
          $env:PATH = ($env:PATH -split ';' |
            Where-Object { $_ -notmatch 'jdk|jre|java|hostedtoolcache' }) -join ';'

          $java = "$env:STANDALONE_JRE\bin\java.exe"
          $jar  = (Get-ChildItem target\extract-tls-secrets-*.jar)[0].FullName

          Write-Host "java.exe : $java  (standalone JRE — no attach.dll)"
          Write-Host "JAVA_HOME: $env:JAVA_HOME  (JDK — has tools.jar)"
          Write-Host ""
          & $java -jar $jar list
        continue-on-error: true

…e instantiated) Three-job workflow (layout-probe → reproduce-windows-attach-dll → workaround-sanity-check) that confirms the ServiceConfigurationError on JDK 8 Temurin when jre\bin is stripped from PATH, and verifies the -Djava.library.path workaround. Triggered via workflow_dispatch. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

The fix is already present in AttachHelper.java — tryLoadLibrary() finds attach.dll relative to JAVA_HOME and prints "Loaded attach <path>". Update Job 2 assertion to verify the fallback fires and no ServiceConfigurationError appears when jre\bin is stripped from PATH. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

- Job 2: updated assertion handles both cases — fix fallback fires ("Loaded attach" present) or JVM finds attach.dll via sun.boot.library.path (no fallback needed, no error) - Job 3 (new): reverts the loadAttachLibrary() guard in source, also strips sun.boot.library.path of jre\bin via JVM flag, then runs the unfixed jar to attempt a conclusive reproduction of the ServiceConfigurationError - layout-probe: also prints sun.boot.library.path for diagnosis - workaround-sanity-check: now runs in parallel with Job 3 (both depend on verify-fix passing) https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

Replace the unreliable GITHUB_ENV PATH-stripping approach with direct JVM flags: -Djava.library.path=. -Dsun.boot.library.path=. Setting both to '.' (current dir, no attach.dll) forces System.loadLibrary("attach") to fail, without touching the process PATH. This makes every job step self-contained and reliable. - verify-fix: fix's tryLoadLibrary() finds attach.dll via JAVA_HOME absolute path; "Loaded attach" must appear - reproduce-without-fix: remove loadAttachLibrary() guard, same flags, assert ServiceConfigurationError is produced - workaround-sanity-check: explicit -Djava.library.path=jre\bin with -Dsun.boot.library.path=. confirms the manual workaround https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

…h isolation Previous attempts to override sun.boot.library.path via -D failed because the JVM overwrites that property at startup after -D arguments are processed. New approach: inject a reflection snippet into the test code that nulls ClassLoader.sys_paths and sets sun.boot.library.path="." at runtime. This forces the next System.loadLibrary("attach") call to re-initialise both search paths as "." (where attach.dll is absent), faithfully simulating an environment where jre\bin is absent from all search paths. - verify-fix: snippet injected into loadAttachLibrary(), fix fallback fires → "Loaded attach" must appear - reproduce-without-fix: snippet in list(), loadAttachLibrary() removed → ServiceConfigurationError must appear - workaround-sanity-check: same as above + -Djava.library.path=jre\bin → usr_paths finds attach.dll, no error https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

…snippets The @'...'@ here-string closing delimiter caused a YAML parse error. Encode the Java injection snippets as base64 and decode them in PowerShell at runtime — no special characters to escape in the YAML source. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

…s manipulation Replace reflection-based sys_paths clearing with a genuine environment setup: - Build and supply JAVA_HOME from Temurin JDK 8 (has jre/bin/attach.dll) - Run the jar using Temurin JRE 8 java.exe (no attach.dll in bin) - JAVA_HOME=JDK so tools.jar and the fix's fallback path are both reachable Without fix: WindowsAttachProvider static init calls System.loadLibrary("attach"), finds nothing on the JRE's sun.boot.library.path, throws ServiceConfigurationError. With fix: loadAttachLibrary() catches UnsatisfiedLinkError and loads attach.dll from $JAVA_HOME/jre/bin (JDK), then VirtualMachine.list() succeeds. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

…-type:jre package-type:jre on Temurin 8 reuses the cached JDK path (Java_Temurin-Hotspot_jdk), so JAVA_HOME_JRE == JAVA_HOME_JDK and attach.dll is present, preventing reproduction. New approach: copy $JAVA_HOME\jre to a temp dir, delete attach.dll from the copy, then run the jar with that copy's java.exe. The copy's sun.boot.library.path (= copy's bin/) has no attach.dll, naturally triggering the ServiceConfigurationError. JAVA_HOME still points to the original JDK for tools.jar and the fix's fallback. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

…loaded The JDK ships two copies of attach.dll: bin\attach.dll — incomplete version used by developer tools; on PATH jre\bin\attach.dll — full JRE version needed by WindowsAttachProvider On Windows, java.library.path includes all PATH directories, so System.loadLibrary("attach") finds bin\attach.dll via PATH even when sun.boot.library.path (jre copy's bin/) has no attach.dll. That DLL loads successfully but doesn't export tempPath(), causing UnsatisfiedLinkError on the native call instead of the expected ServiceConfigurationError. Fix: remove bin\attach.dll too, leaving jre\bin\attach.dll intact for the fix's $JAVA_HOME/jre/bin fallback to load via System.load() (absolute path). https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

Temurin/OpenJDK 8 differs from Oracle JDK 8 in how attach.dll is loaded: - Oracle: WindowsAttachProvider static init calls System.loadLibrary("attach") -> class init fails -> ServiceConfigurationError "could not be instantiated" - Temurin: WindowsAttachProvider has no static library load; tempPath() is a native method called during listVirtualMachines() before any WindowsVirtualMachine is created, so without attach.dll it throws: UnsatisfiedLinkError: WindowsAttachProvider.tempPath() Both confirm the same root cause: attach.dll unreachable without the fix. Update the assertion to accept either error pattern. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

…sert GitHub Actions' PowerShell runner appends: if ((Test-Path variable:LASTEXITCODE)) { exit $LASTEXITCODE } so a non-zero exit from java.exe causes the entire step to fail before the separate assert step can check the output. Reset $LASTEXITCODE = 0 after the java invocation; the assert step then inspects the captured output to determine pass/fail. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

java.library.path on Windows auto-includes all PATH directories, not just java.home\bin. Even after removing bin\attach.dll, another copy (or the jre\bin version) is reachable via PATH, causing System.loadLibrary("attach") to succeed with the wrong DLL — which doesn't export tempPath(). Fix: pass -Djava.library.path=. to explicitly override java.library.path with just the current directory (no attach.dll). Combined with the JRE copy controlling sun.boot.library.path, both sys_paths and usr_paths are clear of attach.dll, so: - reproduce job: System.loadLibrary("attach") fails -> UnsatisfiedLinkError - verify-fix job: loadAttachLibrary() catches it, falls back to System.load($JAVA_HOME/jre/bin/attach.dll) -> "Loaded attach" -> works Also simplify setup steps by removing the now-unnecessary JDK bin removal. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

…anipulation The actual root cause requires no filesystem manipulation: - AgentAttach creates URLClassLoader(cp, null) to load tools.jar - WindowsAttachProvider static init calls System.loadLibrary("attach") - Called from a non-bootstrap classloader, this searches java.library.path (= JDK bin, no attach.dll) not sun.boot.library.path (= JRE bin, has it) - UnsatisfiedLinkError wrapped by SPI loader -> ServiceConfigurationError Standard Temurin JDK 8 reproduces the issue without any env modification. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

Downloads the JRE-only zip (not the JDK) to verify whether attach.dll is present in a standalone JRE installation, and prints its library paths — confirming the real-world scenario that triggers issue #7. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

Disables the fix so the workflow can verify the error occurs without it. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

neykov and others added 12 commits May 30, 2021 22:20

Windows actions

d47c27c

Windows improvements

ffb1663

look into java install

5b76094

testing

e8c7d6e

Trigger reproduce-issue-7 workflow on push to this branch

d7801e5

https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

neykov requested a review from Copilot April 1, 2026 18:36

Copilot started reviewing on behalf of neykov April 1, 2026 18:36 View session

This comment was marked as outdated.

Sign in to view

claude and others added 12 commits April 1, 2026 18:42

Trigger workflow on push to branch

6b63167

https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

standalnoe jre

275cf81

standalnoe jre

79ee010

Merge ; commit '275cf81a6f705e776afe251280148c5559e5235a'

7c6b1cb

path

c0ddd8b

Comment out loadAttachLibrary() to reproduce issue #7

3143830

Disables the fix so the workflow can verify the error occurs without it. https://claude.ai/code/session_01R7dUoeZm6vv7V1HGKVuseV

neykov closed this Apr 3, 2026

neykov deleted the claude/reproduce-issue-7-Qj92G branch April 3, 2026 15:15

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Windows actions#30

Windows actions#30
neykov wants to merge 25 commits into
masterfrom
claude/reproduce-issue-7-Qj92G

neykov commented Apr 1, 2026 •

edited

Loading

Uh oh!

This comment was marked as outdated.

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

neykov commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ServiceConfigurationError: WindowsAttachProvider could not be instantiated

Error

Root Cause

Key facts

Failure chain

Variant failure

Steps to Reproduce

Uh oh!

This comment was marked as outdated.

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

neykov commented Apr 1, 2026 •

edited

Loading